home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
8_7_01.tro
< prev
next >
Wrap
Text File
|
1991-12-22
|
112KB
|
4,382 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v'|.5i'
.sp 1P
.ce 1000
\v'12P'
\s12FASCICLE\ VIII.7
\v'4P'
.RT
.ce 0
.sp 1P
.ce 1000
\fBRecommendations\ X.400\ to\ X.420\fR \v'2P'
.EF '% \ \ \ ^''
.OF ''' \ \ \ ^ %'
.ce 0
.sp 1P
.ce 1000
\fBDATA\ COMMUNICATION\ NETWORKS:\fR
.ce 0
.sp 1P
.ce 1000
\fBMESSAGE\ HANDLING\ SYSTEMS\fR
.ce 0
.sp 1P
.LP
.rs
.sp 30P
.LP
.bp
.LP
\fBMONTAGE:\fR page 2 = page blanche.
.sp 1P
.RT
.LP
.bp
.sp 2P
.LP
\fBRecommendation\ X.400\fR
.FS
Recommendation F.400 is identical to
X.400.
.FE
.RT
.sp 2P
.sp 1P
.ce 1000
\fBMESSAGE\ HANDLING\ SYSTEM\ AND\ SERVICE\ OVERVIEW\fR
.EF '% Fascicle\ VIII.7\ \(em\ Rec.\ X.400''
.OF '''Fascicle\ VIII.7\ \(em\ Rec.\ X.400 %'
.ce 0
.sp 1P
.PP
The establishment in various countries of telematic services and computer
based store and forward messaging services in association with
public networks creates a need to produce standards to facilitate international
message exchange between subscribers to such services.
.sp 1P
.RT
.sp 2P
.LP
The\ CCITT,
.sp 1P
.RT
.sp 1P
.LP
\fIconsidering\fR
.sp 9p
.RT
.PP
(a)
the need for message handling systems;
.PP
(b)
the need to transfer and store messages of different
types;
.PP
(c)
that Recommendation X.200 defines the reference model of open systems interconnection
for CCITT applications;
.PP
(d)
that Recommendations X.208, X.217, X.218 and X.219
provide the foundation for CCITT applications;
.PP
(e)
that the X.500\(hySeries Recommendations define directory systems;
.PP
(f)
that message handling systems are defined in a series of Recommendations:
X.400, X.402, X.403, X.407, X.408, X.411, X.413 and X.419;
.PP
(g)
that interpersonal message is defined in
Recommendation\ X.420 and T.330;
.PP
(h)
that several F\(hySeries Recommendations describe public message handling
services: F.400, F.401, F.410 and F.420;
.PP
(i)
that several F\(hySeries Recommendations describe
intercommunication between public message handling services and other services:
F.421, F.415 and F.422,
.sp 1P
.LP
\fIunanimously declares\fR
.sp 9p
.RT
.PP
the view that the overall system and service overview of message handling
is defined in this Recommen
dation.
.LP
.sp 1
.bp
.sp 1P
.ce 1000
CONTENTS
.ce 0
.sp 1P
.sp 2P
.LP
PART\ 1\ \(em\ \fIIntroduction\fR
.sp 1P
.RT
.sp 1P
.LP
0
\fIIntroduction\fR
.sp 9p
.RT
.sp 1P
.LP
1
\fIScope\fR
.sp 9p
.RT
.sp 1P
.LP
2
\fIReferences\fR
.sp 9p
.RT
.sp 1P
.LP
3
\fIDefinitions\fR
.sp 9p
.RT
.sp 1P
.LP
4
\fIAbbreviations\fR
.sp 9p
.RT
.sp 1P
.LP
5
\fIConventions\fR
.sp 9p
.RT
.sp 2P
.LP
PART\ 2\ \(em\ \fIGeneral description of MHS\fR
.sp 1P
.RT
.sp 1P
.LP
6
\fIPurpose\fR
.sp 9p
.RT
.sp 1P
.LP
7
\fIFunctional model of MHS\fR
.sp 9p
.RT
.LP
7.1
Description of the MHS model\fR
.LP
7.2
Structure of messages
.LP
7.3
Application of the MHS model
.LP
7.4
Message store
.sp 1P
.LP
8
\fIMessage transfer service\fR
.sp 9p
.RT
.LP
8.1
Submission and delivery
.LP
8.2
Transfer
.LP
8.3
Notifications
.LP
8.4
User agent
.LP
8.5
Message store
.LP
8.6
Access unit
.LP
8.7
Use of the MTS in the provision of public services
.sp 1P
.LP
9
\fIIPM service\fR
.sp 9p
.RT
.LP
9.1
IPM service functional model
.LP
9.2
Structure of IP\(hymessages
.LP
9.3
IP\(hynotifications
.sp 1P
.LP
10
\fIIntercommunication with physical delivery services\fR
.sp 9p
.RT
.LP
10.1
Introduction
.LP
10.2
Organizational configurations
.sp 1P
.LP
11
\fISpecialized access\fR
.sp 9p
.RT
.LP
11.1
Introduction
.LP
11.2
Teletex access
.LP
11.3
Telex access
.sp 2P
.LP
PART\ 3\ \(em\ \fICapabilities of MHS\fR
.sp 1P
.RT
.sp 1P
.LP
12
\fINaming and addressing\fR
.sp 9p
.RT
.LP
12.1
Introduction
.LP
12.2
Directory names
.LP
12.3
O/R names
.LP
12.4
O/R addresses
.bp
.sp 1P
.LP
13
\fIMHS use of directory\fR
.sp 9p
.RT
.LP
13.1
Introduction
.LP
13.2
Functional model
.LP
13.3
Physical configurations
.sp 1P
.LP
14
\fIDistribution lists in MHS\fR
.sp 9p
.RT
.LP
14.1
Introduction
.LP
14.2
Properties of a DL
.LP
14.3
Submission
.LP
14.4
DL use of a directory
.LP
14.5
DL expansion
.LP
14.6
Nesting
.LP
14.7
Recursion control
.LP
14.8
Delivery
.LP
14.9
Routing loop control
.LP
14.10
Notifications
.LP
14.11
DL handling policy
.sp 1P
.LP
15
\fISecurity capabilities of MHS\fR
.sp 9p
.RT
.LP
15.1
Introduction
.LP
15.2
MHS security threats
.LP
15.3
Security model
.LP
15.4
MHS security features
.LP
15.5
Security management
.sp 1P
.LP
16
\fIConversion in MHS\fR
.sp 9p
.RT
.sp 1P
.LP
17
\fIUse of the MHS in provision of public services\fR
.sp 9p
.RT
.sp 2P
.LP
PART\ 4\ \(em\ \fIElements of service\fR
.sp 1P
.RT
.sp 1P
.LP
18
\fIPurpose\fR
.sp 9p
.RT
.sp 1P
.LP
19
\fIClassification\fR
.sp 9p
.RT
.LP
19.1
Purpose of classification
.LP
19.2
Basic message transfer service
.LP
19.3
MT service optional user facilities
.LP
19.4
Base MH/PD service intercommunication
.LP
19.5
Optional user facilities for MH/PD service
intercommunication
.LP
19.6
Base message store
.LP
19.7
MS optional user facilities
.LP
19.8
Basic interpersonal messaging service
.LP
19.9
IPM service optional user facilities
.sp 1P
.LP
\fIAnnex\ A\fR \(em
Glossary of terms
.sp 9p
.RT
.LP
\fIAnnex\ B\fR \(em
Definitions of elements of service
.LP
\fIAnnex\ C\fR \(em
Elements of service modifications with respect to the 1984
version
.LP
\fIAnnex\ D\fR \(em
Differences between CCITT Recommendation F.400 and ISO
Standard\ 10021\(hy1
.bp
.LP
PART\ 1\ \(em\ INTRODUCTION
.sp 1P
.RT
.sp 2P
.LP
\fB0\fR \fBIntroduction\fR
.sp 1P
.RT
.PP
This Recommendation is one of a set of Recommendations for message handling.
The entire set provides a comprehensive specification for message
handling comprising any number of cooperating open\(hysystems.
.PP
Message handling systems and services enable users to exchange
messages on a store\(hyand\(hyforward basis. A message submitted by one
user, the
originator, is conveyed by the message transfer system (MTS), the principal
component of a larger message handling system (MHS), and is subsequently
delivered to one or more additional users, the message's recipients.
.PP
An MHS comprises a variety of interconnected functional entities.
Message transfer agents (MTAs) cooperate to perform the store\(hyand\(hyforward
message transfer function. Message stores (MSs) provide storage for messages
and enable their submission, retrieval and management. User agents (UAs)
help users access MHS. Access units (AUs) provide links to other communication
systems and services of various kinds (e.g.\ other telematic services, postal
services).
.PP
This Recommendation specifies the overall system and service
description of message handling capabilities.
.RT
.sp 2P
.LP
\fB1\fR \fBScope\fR
.sp 1P
.RT
.PP
This Recommendation defines the overall system and service of an
MHS and serves as a general overview of MHS.
.PP
Other aspects of message handling systems and services are defined in other
Recommendations. The layout of Recommendations defining the message
handling system and services is shown in Table\ 1/X.400. The public services
built on MHS, as well as access to and from the MHS for public services are
defined in the F.400\(hySeries of Recommendations.
.PP
The technical aspects of MHS are defined in the X.400\(hySeries of
Recommendations. The overall system architecture of MHS is defined in
Recommendation\ X.402.
.RT
.LP
.rs
.sp 25P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T1.400]\fR
.ce
TABLE\ 1/X.400
.ce
\fBStructure of MHS Recommendations\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(84p) | cw(24p) sw(24p) | cw(24p) sw(24p) | cw(24p) sw(24p) , ^ | c | c | c | c | c | c.
T{
Name of Recommendation/Standard
T} Joint MHS Joint support CCITT only
CCITT ISO CCITT ISO System Service
_
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) .
MHS: System and service overview X.400 10021\(hy1 F.400
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) .
MHS: Overall architecture X.402 10021\(hy2
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | cw(24p) | cw(24p) .
MHS: Conformance testing X.403
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | cw(24p) | cw(24p) .
MHS: T{
Abstract service definition conventions
T} X.407 10021\(hy3
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | cw(24p) | cw(24p) .
MHS: T{
Encoded information type conversion rules
T} X.408
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | cw(24p) | cw(24p) .
MHS: T{
MTS:
Abstract service definition and procedures
T} X.411 10021\(hy4
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | cw(24p) | cw(24p) .
MHS: T{
MS:
Abstract service definition
T} X.413 10021\(hy5
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) .
MHS: Protocol specifications X.419 10021\(hy6
.T&
lw(18p) | lw(66p) | cw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) .
MHS: T{
Interpersonal messaging system
T} X.420 10021\(hy7
.T&
lw(84p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) .
Telematic access to IPMS T.330
_
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) .
MHS: T{
Naming and addressing for public MH services
T} F.401
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) .
MHS: T{
The public message transfer service
T} F.410
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) .
MHS: T{
Intercommunication with public physical delivery services
T} F.415
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) .
MHS: The public IPM service F.420
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) .
MHS: T{
Intercommunication between IPM service and telex
T} F.421
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | lw(24p) | cw(24p) .
MHS: T{
Intercommunication between IPM service and teletex
T} F.422
_
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: Basic reference model X.200 7498
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: T{
Specification of abstract syntax notation one (ASN.1)
T} X.208 8824
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: T{
Specification of basic encoding rules for abstract syntax
notation one (ASN.1)
T} X.209 8825
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: T{
Association control: service definition
T} X.217 8649
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: T{
Reliable transfer: model and service definition
T} X.218 9066\(hy1
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: T{
Remote operations: model, notation and service definition
T} X.219 9072\(hy1
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: T{
Association control: protocol specification
T} X.227 8650
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: T{
Reliable transfer: protocol specification
T} X.228 9066\(hy2
.T&
lw(18p) | lw(66p) | lw(24p) | lw(24p) | cw(24p) | lw(24p) | lw(24p) | lw(24p) .
OSI: T{
Remote operations: protocol specification
T} X.229 9072\(hy2
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 1/X.400 [T1.400], p. 1\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fB2\fR \fBReferences\fR
.sp 1P
.RT
.PP
This Recommendation cites the documents listed below:
.RT
.LP
Recommendation\ F.60
Operational provisions for the
international telex service
.LP
Recommendation\ F.69
Plan for the telex destination codes
.LP
Recommendation\ F.72
International telex store\(hyand\(hyforward \(em
General principles and operational aspects
.LP
Recommendation\ F.160
General operational provisions for the
international public fascimile services
.LP
Recommendation\ F.200
Teletex service
.LP
Recommendation\ F.300
Videotex service
.LP
Recommendation\ F.400
Message handling \(em System and service
overview (see also ISO\ 10021\(hy1)
.LP
Recommendation\ F.401
Message handling services \(em Naming and
addressing for public message handling services
.LP
Recommendation\ F.410
Message handling services \(em The public
message transfer service
.LP
Recommendation\ F.415
Message handling services \(em
Intercommunication with public physical delivery services
.LP
Recommendation\ F.420
Message handling services \(em The public
interpersonal messaging service
.LP
Recommendation\ F.421
Message handling services \(em
Intercommunication between the IPM service and the telex service
.LP
Recommendation\ F.422
Message handling services \(em
Intercommunication between the IPM service and the teletex service
.LP
Recommendation\ T.61
Character repertoire and coded character
sets for the international teletex service
.LP
Recommendation\ T.330
Telematic access to IPMS
.LP
Recommendation\ U.80
International teletex store\(hyand\(hyforward \(em
Access from telex
.LP
Recommendation\ U.204
Interworking between the telex service and
the public interpersonal messaging service
.LP
Recommendation\ X.200
Reference model of open systems
interconnection for CCITT applications (see also ISO\ 7498)
.LP
Recommendation\ X.208
Specification of abstract syntax notation
one (ASN.1) (see also ISO\ 8824)
.LP
Recommendation\ X.209
Specification of basic encoding rules for
abstract syntax notation one (ASN.1) (see also ISO\ 8825)
.LP
Recommendation\ X.217
Association control: Service definitions
(see also ISO\ 8649)
.LP
Recommendation\ X.218
Reliable transfer model: Service
definition (see also ISO/IEC\ 9066\(hy1)
.LP
Recommendation\ X.219
Remote operations model: Notation and
service definition (see also ISO/IEC\ 9072\(hy1)
.LP
Recommendation\ X.400
Message handling \(em System and service
overview (see also ISO/IEC\ 10021\(hy1)
.LP
Recommendation\ X.402
Message handling systems \(em Overall
architecture (see also ISO/IEC\ 10021\(hy2)
.LP
Recommendation\ X.403
Message handling systems \(em Conformance
testing
.LP
Recommendation\ X.407
Message handling systems \(em Abstract
service definition conventions (see also ISO/IEC\ 10021\(hy3)
.LP
Recommendation\ X.408
Message handling systems \(em Encoded
information type convention rules
.LP
Recommendation\ X.411
Message handling systems \(em Message
transfer system: Abstract service definition and procedures (see also
ISO/IEC\ 10021\(hy4)
.bp
.LP
Recommendation\ X.413
Message handling systems \(em Message store:
Abstract service definition (see also ISO/IEC\ 10021\(hy5)
.LP
Recommendation\ X.419
Message handling systems \(em Protocol
specifications (see also ISO/IEC\ 10021\(hy6)
.LP
Recommendation\ X.420
Message handling systems \(em Interpersonal
messaging system
.LP
(see also ISO/IEC\ 10021\(hy7)
.LP
Recommendation\ X.500
Directory \(em Overview (see also
ISO/IEC\ 9594\(hy1)
.LP
Recommendation\ X.501
Directory \(em Models (see also
ISO/IEC\ 9594\(hy2)
.LP
Recommendation\ X.509
Directory \(em Authentication (see also
ISO/IEC\ 9594\(hy8)
.LP
Recommendation\ X.511
Directory \(em Abstract service definition
(see also ISO/IEC\ 9594\(hy3)
.LP
Recommendation\ X.518
Directory \(em Procedures for distributed
operations (see also ISO/IEC\ 9594\(hy4)
.LP
Recommendation\ X.519
Directory \(em Protocol specifications (see
also ISO/IEC\ 9594\(hy5)
.LP
Recommendation\ X.520
Directory \(em Selected attribute types (see
also ISO/IEC\ 9594\(hy6)
.LP
Recommendation\ X.521
Directory \(em Selected object classes (see
also ISO/IEC\ 9594\(hy7)
.sp 2P
.LP
\fB3\fR \fBDefinitions\fR
.sp 1P
.RT
.PP
This Recommendation uses the terms listed below, and those defined in Annex\
A.
.PP
Definitions of the elements of service applicable to MHS are contained
in Annex\ B.
.RT
.sp 1P
.LP
3.1
\fIOpen systems interconnection\fR
.sp 9p
.RT
.PP
This Recommendation uses the following terms defined in
Recommendation\ X.200:
.RT
.LP
a)
Application layer;
.LP
b)
Application\(hyprocess;
.LP
c)
Open systems interconnection;
.LP
d)
OSI reference model.
.sp 1P
.LP
3.2
\fIDirectory systems\fR
.sp 9p
.RT
.PP
This Recommendation uses the following terms defined in
Recommendation\ X.500:
.RT
.LP
a)
directory entry;
.LP
b)
directory system agent;
.LP
c)
directory system;
.LP
d)
directory user agent.
.PP
This Recommendation uses the following terms defined in
Recommendation\ X.501:
.LP
e)
attribute;
.LP
f)
group;
.LP
g)
member;
.LP
h)
name.
.sp 2P
.LP
\fB4\fR \fBAbbreviations\fR \v'3p'
.sp 1P
.RT
.LP
A
Additional
\
.LP
ADMD
Administration management domain
\
.LP
AU
Access unit
\
.LP
CA
Contractual agreement
\
.LP
DL
Distribution list
\
.LP
DSA
Directory system agent
\
.LP
DUA
Directory user agent
\
.bp
.LP
E
Essential
\
.LP
EIT
Encoded information type
\
.LP
I/O
Input/output
\
.LP
IP
Interpersonal
\
.LP
IPM
Interpersonal messaging
\
.LP
IPMS
Interpersonal messaging system
\
.LP
MD
Management domain
\
.LP
MH
Message handling
\
.LP
MHS
Message handling system
\
.LP
MS
Message store
\
.LP
MT
Message transfer
\
.LP
MTA
Message transfer agent
\
.LP
MTS
Message transfer system
\
.LP
N/A
Not applicable
\
.LP
O/R
Originator/recipient
\
.LP
OSI
Open system interconnection
\
.LP
PD
Physical delivery
\
.LP
PDAU
Physical delivery access unit
\
.LP
PDS
Physical delivery system
\
.LP
PM
Per\(hymessage
\
.LP
PR
Per\(hyrecipient
\
.LP
PRMD
Private management domain
\
.LP
PTLXAU
Public telex access unit
\
.LP
TLMA
Telematic agent
\
.LP
TLXAU
Telex access unit
\
.LP
TTX
Teletex
\
.LP
UA
User agent
\
.sp 2P
.LP
\fB5\fR \fBConventions\fR
.sp 1P
.RT
.PP
In this Recommendation the expression \*QAdministration\*U is used for
shortness to indicate a telecommunication Administration, a recognized
private operating agency, and, in the case of intercommunication with public
delivery service, a postal Administration.
.PP
\fINote\fR \ \(em\ This Recommendation is identical to Recommendation F.400.
Because of the desired alignment with ISO, the conventions of ISO standards
have been adopted for the structure of this text. These conventions differ
from the CCITT style. The other Recommendations of the X.400\(hySeries
are in
accordance with CCITT conventions.
.RT
.LP
.rs
.sp 07P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.LP
PART\ 2\ \(em\ GENERAL DESCRIPTION OF MHS
.sp 1P
.RT
.sp 2P
.LP
\fB6\fR \fBPurpose\fR
.sp 1P
.RT
.PP
This Recommendation is one of a set of Recommendations and describes the
system model and elements of service of the message handling system (MHS)
and services. This Recommendation overviews the capabilities of an MHS
that are used by Administrations for the provision of public MH services
to enable users to exchange messages on a store\(hyand\(hyforward basis.
.PP
The message handling system is designed in accordance with the
principles of the reference model of open systems interconnection (OSI
reference model) for CCITT applications (Recommendation\ X.200) and uses the
presentation layer services and services offered by other, more general,
application service elements. An MHS can be constructed using any network
fitting in the scope of OSI. The message transfer service provided by the
MTS is application independent. An example of a standardized application
is the IPM service. End systems can use the MT service for specific applications
that are defined bilaterally.
.PP
Message handling services provided by Administrations belong to the
group of telematic services defined in F\(hySeries Recommendations.
.PP
Various other telematic services and telex (Recommendations F.60,
F.160, F.200, F.300,\ etc.), data transmission services (X.1), or physical
delivery services (F.415) gain access to, and intercommunicate with, the IPM
service or intercommunicate with each other, via access units.
.PP
Elements of service are the service features provided through the
application processes. The elements of service are considered to be components
of the services provided to users and are either elements of a basic service
or they are \fIoptional user facilities\fR , classified either as \fIessential
optional\fR \fIuser facilities\fR , or as \fIadditional optional user facilities\fR
.
.RT
.sp 2P
.LP
\fB7\fR \fBFunctional model of MHS\fR
.sp 1P
.RT
.PP
The MHS functional model serves as a tool to aid in the development of
Recommendations for MHS, and aids in describing the basic concepts that
can be depicted graphically. It comprises several different functional
components that work together to provide MH services. The model can be
applied to a number of different physical and organizational configurations.
.RT
.sp 1P
.LP
7.1
\fIDescription of the MHS model\fR
.sp 9p
.RT
.PP
A functional view of the MHS model is shown in Figure 1/X.400. In this
model, a user is either a person or a computer process. Users are either
direct users (i.e.\ engage in message handling by direct use of MHS), or
are
indirect users (i.e.\ engage in message handling through another communication
system (e.g.\ a physical delivery system) that is linked to MHS). A user
is
referred to as either an originator (when sending a message) or a recipient
(when receiving a message). Message handling elements of service define
the set of message types and the capabilities that enable an originator
to transfer
messages of those types to one or more recipients.
.RT
.PP
An originator prepares messages with the assistance of his user
agent. A user agent (UA) is an application process that interacts with the
message transfer system (MTS) or a message store (MS), to submit messages on
behalf of a single user. The MTS delivers the messages submitted to it,
to one or more recipient UAs, access units (AUs), or MSs, and can return
notifications to the originator. Functions performed solely by the UA and
not standardized as part of the message handling elements of service are
called local functions. A UA can accept delivery of messages directly from
the MTS, or it can use the
capabilities of an MS to receive delivered messages for subsequent retrieval
by the UA.
.PP
The MTS comprises a number of message transfer agents (MTAs).
Operating together, in a store\(hyand\(hyforward manner, the MTAs transfer
messages and deliver them to the intended recipients.
.PP
Access by indirect users of MHS is accomplished by AUs. Delivery to
indirect users of MHS is accomplished by AUs, such as in the case of physical
delivery, by the physical delivery access unit (PDAU).
.PP
The message store (MS) is an optional general purpose capability of
MHS that acts as an intermediary between the UA and the MTA. The MS is
depicted in the MHS functional model shown in Figure\ 1/X.400. The MS is
a functional
entity whose primary purpose is to store and permit retrieval of delivered
messages. The MS also allows for submission from, and alerting to the UA.
.PP
The collection of UAs, MSs, AUs and MTAs is called the message
handling system (MHS).
.bp
.RT
.LP
.rs
.sp 29P
.ad r
\fBFigure 1/X.400, p. 2\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
7.2
\fIStructure of messages\fR
.sp 9p
.RT
.PP
The basic structure of messages conveyed by the MTS is shown in
Figure\ 2/X.400. A message is made up of an envelope and a content. The
envelope carries information that is used by the MTS when transferring
the message
within the MTS. The content is the piece of information that the originating
UA wishes delivered to one or more recipient UAs. The MTS neither modifies
or
examines the content, except for conversion (see \(sc\ 16).
.RT
.LP
.rs
.sp 12P
.ad r
\fBFigure 2/X.400, p. 3\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
7.3
\fIApplication of the MHS model\fR
.sp 1P
.RT
.sp 1P
.LP
7.3.1
\fIPhysical mapping\fR
.sp 9p
.RT
.PP
Users access UAs for message processing purposes, for example, to create,
present, or file messages. A user can interact with a UA via an
input/output device or process (e.g.\ keyboard, display, printer,\ etc.). A UA
can be implemented as a (set of) computer process(es) in an intelligent
terminal.
.PP
A UA and MTA can be co\(hylocated in the same system, or a UA/MS can be
implemented in physically separate systems. In the first case the UA accesses
the MT elements of service by interacting directly with the MTA in the
same
system. In the second case, the UA/MS will communicate with the MTA via
standardized protocols specified for MHS. It is also possible for an MTA
to be implemented in a system without UAs or MSs.
.PP
Some possible physical configurations are shown in Figures 3/X.400 and
4/X.400. The different physical systems can be connected by means of dedicated
lines or switched network connections.
.RT
.LP
.rs
.sp 10P
.ad r
\fBFigure 3/X.400, p. 4\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 13P
.ad r
\fBFigure 4/X.400, p. 5\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
7.3.2
\fIOrganizational mapping\fR
.sp 9p
.RT
.PP
An Administration or organization can play various roles in
providing message handling services. An organization in this context can
be a company or a non\(hycommercial enterprise.
.PP
The collection of at least one MTA, zero or more UAs, zero or more
MSs, and zero or more AUs operated by an Administration or organization
constitutes a management domain (MD). An MD managed by an Administration is
called an Administration management domain (ADMD). An MD managed by an
organization other than an Administration is called a private management
domain (PRMD). An MD provides message handling services in accordance with
the
classification of elements of service as described in \(sc\ 19. The relationships
between management domains is shown in Figure\ 5/X.400.
.bp
.RT
.LP
.rs
.sp 30P
.ad r
\fBFigure 5/X.400, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
\fINote\ 1\fR \ \(em\ It should be recognized that the provision of support
of private messaging systems by CCITT members falls within the framework
of
national regulations. Thus the possibilities mentioned in this paragraph
may or may not be offered by an Administration which provides message handling
services. In addition, the UAs depicted in Figure\ 5/X.400 do not imply
that UAs belonging to an MD must be exclusively located in the same country
as their
MDs.
.PP
\fINote\ 2\fR \ \(em\ Direct interactions between PRMDs and internal interactions
within an MD are outside the scope of this Recommendation.
.PP
\fINote\ 3\fR \ \(em\ An Administration, in the context of CCITT, that
manages an ADMD, is understood as being a member of ITU or a recognized
private operating agency (RPOA), registered by a country with the ITU.
.RT
.sp 1P
.LP
7.3.3
\fIAdministration management domain\fR
.sp 9p
.RT
.PP
In one country one or more ADMDs can exist. An ADMD is
characterized by its provision of relaying functions between other management
domains and the provision of message transfer service for the applications
provided within the ADMD.
.PP
An Administration can provide access for its users to the ADMD in one or
more of the following ways:
.RT
.LP
\(em
users to Administration provided UA
.LP
\(em
private UA to Administration MTA
.LP
\(em
private UA to Administration MS
.LP
\(em
private UA to Administration MTA
.LP
\(em
user to Administration provided UA.
.PP
See also the examples of configurations shown in Figure 3/X.400
and Figure 4/X.400.
.bp
.PP
Administration provided UAs can exist as part of an intelligent
terminal that the user can use to access MHS. They can also exist as part of
Administration resident equipment being part of MHS, in which case the user
obtains access to the UA via an I/O device.
.PP
In the case of a private UA, the user has a private stand\(hyalone UA
which interacts with the Administration provided MTA or MS, using submission,
delivery and retrieval functions. A private, stand\(hyalone UA can be associated
with one or more MDs, provided that the required naming conventions are
preserved.
.PP
A private MTA as part of an PRMD can access one or more ADMDs in a
country, following national regulations.
.PP
Access can also be provided by Administration provided AUs described in
\(sc\(sc\ 10 and\ 11.
.RT
.sp 1P
.LP
7.3.4
\fIPrivate management domain\fR
.sp 9p
.RT
.PP
An organization other than an Administration can have one or more MTA(s),
and zero or more UAs, AUs and MSs forming a PRMD which can interact
with an ADMD on an MD to MD (MTA to MTA) basis. A PRMD is characterized
by the provision of messaging functions within that management domain.
.PP
A PRMD is considered to exist entirely within one country. Within that
country, the PRMD can have access to one or more ADMDs as shown in
Figure\ 5/X.400. However, in the case of a specific interaction between
a PRMD and an ADMD (such as when a message is transferred between MDs),
the PRMD is
considered to be associated only with that ADMD. A PRMD will not act as
a relay between two ADMDs.
.PP
In the interaction between a PRMD and an ADMD, the ADMD takes
responsibility for the actions of the PRMD which are related to the
interaction. In addition to ensuring that the PRMD properly provides the
message transfer service, the ADMD is responsible for ensuring that the
accounting, logging, quality of service, uniqueness of names, and related
operations of the PRMD are correctly performed. As a national matter, the
name of a PRMD can be either nationally unique or relative to the associated
ADMD. If a PRMD is associated with more than one ADMD, the PRMD can have
more than
one name.
.RT
.sp 1P
.LP
7.4
\fIMessage store\fR
.sp 9p
.RT
.PP
Because UAs can be implemented on a wide variety of equipment,
including personal computers, the MS can complement a UA implemented, for
example, on a personal computer by providing a more secure, continuously
available storage mechanism to take delivery of messages on the user agent's
behalf. The MS retrieval capability provides users who subscribe to an
MS with basic message retrieval capabilities potentially applicable to
messages of all types. Figure\ 6/X.400 shows the delivery, and subsequent
retrieval of messages that are delivered to an MS, and the indirect submission
of messages via the
MS.
.RT
.LP
.rs
.sp 7P
.ad r
\fBFigure 6/X.400, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
One MS acts on behalf of only one user (one O/R address), i.e. it does
not provide a common or shared MS capability to several users (see also
PRMD3 of Figure\ 5/X.400).
.PP
When subscribing to an MS, all messages destined for the UA are
delivered to the MS only. The UA, if on line, can receive alerts when certain
messages are delivered to the MS. Messages delivered to an MS are considered
delivered from the MTS perspective.
.PP
When a UA submits a message through the MS, the MS is in general
transparent and submits it to the MTA before confirming the success of the
submission to the UA. However, the MS can expand the message if the UA
requests the forwarding of messages that exist in the MS.
.bp
.PP
Users are also provided with the capability to request the MS to
forward selected messages automatically upon delivery.
.PP
The elements of service describing the features of the MS are defined in
Annex\ B and classified in \(sc\ 19. Users are provided with the capability
based on various criteria, to get counts and lists of messages, to fetch
messages,
and to delete messages, currently held in the MS.
.RT
.sp 1P
.LP
7.4.1
\fIPhysical configurations\fR
.sp 9p
.RT
.PP
The MS can be physically located with respect to the MTA in a
number of ways. The MS can be co\(hylocated with the UA, co\(hylocated
with the MTA, or stand\(hyalone. From an external point of view, a co\(hylocated
UA and MS are
indistinguishable from a stand\(hyalone UA. Co\(hylocating the MS with
the MTA offers significant advantages which will probably make it the predominant
configuration.
.RT
.sp 1P
.LP
7.4.2
\fIOrganizational configurations\fR
.sp 9p
.RT
.PP
Either ADMDs or PRMDs can operate MSs. In the case of
Administration supplied MSs, the subscriber either provides his own UA
or makes use of an Administration supplied UA via an I/O device. In either
case, all the subscriber's messages are delivered to the MS for subsequent
retrieval.
.PP
The physical and organizational configurations described above are
examples only and other equally cases can exist.
.RT
.sp 2P
.LP
\fB8\fR \fBMessage transfer service\fR
.sp 1P
.RT
.PP
The MTS provides the general, application independent,
store\(hyand\(hyforward message transfer service. The elements of service
describing the features of the MT service are defined in Annex\ B and classified
in \(sc\ 19. Provision of public message transfer service by Administrations
is described in Recommendation\ F.410.
.RT
.sp 1P
.LP
8.1
\fISubmission and delivery\fR
.sp 9p
.RT
.PP
The MTS provides the means by which UAs exchange messages. There
are two basic interactions between MTAs and UAs and/or MSs:
.RT
.LP
1)
The submission interaction is the means by which an
originating UA or MS transfers to an MTA the content of a message and the
submission envelope. The submission envelope contains the information that
the MTS requires to provide the requested elements of service.
.LP
2)
The delivery interaction is the means by which the MTA
transfers to a recipient UA or MS the content of a message plus the delivery
envelope. The delivery envelope contains information related to delivery
of the message.
.PP
In the submission and delivery interactions, responsibility for
the message is passed between the MTA and the UA or MS.
.sp 1P
.LP
8.2
\fITransfer\fR
.sp 9p
.RT
.PP
Starting at the originator's MTA, each MTA transfers the message to another
MTA until the message reaches the recipient's MTA, which then delivers
it to the recipient UA or MS using the delivery interaction.
.PP
The transfer interaction is the means by which one MTA transfers to
another MTA the content of a message plus the transfer envelope. The transfer
envelope contains the information related to the operation of the MTS plus
information that the MTS requires to provide elements of service requested
by the originating UA.
.PP
MTAs transfer messages containing any type of binary coded
information. MTAs neither interpret not alter the content of messages except
when performing a conversion.
.RT
.sp 1P
.LP
8.3
\fINotifications\fR
.sp 9p
.RT
.PP
Notifications in the MT service comprise the delivery and
non\(hydelivery notifications. When a message, or probe, cannot be delivered by
the MTS, a non\(hydelivery notification is generated and returned to the
originator in a report signifying this. In addition, an originator can
specifically ask for acknowledgement of successful delivery through use
of the delivery notification element of service on submission.
.bp
.RT
.sp 1P
.LP
8.4
\fIUser agent\fR
.sp 9p
.RT
.PP
The UA uses the MT service provided by the MTS. A UA is a
functional entity by means of which a single direct user engages in message
handling.
.PP
UAs are grouped into classes based on the type of content of messages they
can handle. The MTS provides a UA with the ability to identify its class
when sending messages to other UAs. UAs within a given class are referred
to as cooperating UAs since they cooperate with each other to enhance the
communication amongst their respective users.
.PP
\fINote\fR \ \(em\ A UA can support more than one type of message content,
and hence belong to several UA classes.
.RT
.sp 1P
.LP
8.5
\fIMessage store\fR
.sp 9p
.RT
.PP
The message store (MS) uses the MT service provided by the MTS. An MS is
a functional entity associated with a user's UA. The user can submit
messages through it, and retrieve messages that have been delivered to
the\ MS.
.RT
.sp 1P
.LP
8.6
\fIAccess unit\fR
.sp 9p
.RT
.PP
An access unit (AU) uses the MT service provided by the MTS. An AU is a
functional entity associated with an MTA to provide for intercommunication
between MHS and another system or service.
.RT
.sp 1P
.LP
8.7
\fIUse of the MTS in the provision of various services\fR
.sp 9p
.RT
.PP
The MTS is used by application specific services for the provision of message
handling services of various types. The interpersonal messaging
service, described in \(sc\ 9, is one example of this. Other services can
be built on the foundation of the MTS, either with corresponding recommendations
or as private applications.
.RT
.sp 2P
.LP
\fB9\fR \fBIPM service\fR
.sp 1P
.RT
.PP
The interpersonal message service (IPM service) provides a user
with features to assist in communicating with other IPM service users.
The IPM service uses the capabilities of the MT service for sending and
receiving
interpersonal messages. The elements of service describing the features
of the IPM service are defined in Annex\ B and classified in \(sc\ 19.
The provision of
public interpersonal messaging service by Administrations is described in
Recommendation\ F.420.
.RT
.sp 1P
.LP
9.1
\fIIPM service functional model\fR
.sp 9p
.RT
.PP
Figure 7/X.400 shows the functional model of the IPM service. The UAs used
in the IPM service (IPM\(hyUAs) comprise a specific class of cooperating
UAs. The optional access units shown (TLMA, PTLXAU) allow for teletex and
telex
.PP
users to intercommunicate with the IPM service. The optional access unit
(TLMA) also allows for teletex users to participate in the IPM service
(see also
\(sc\ 11). The optional physical delivery access unit (PDAU) allows IPM
users to
send messages to users outside the IPM service who have no access to MHS.
The message store can optionally be used by IPM users to take delivery
of messages on their behalf.
.RT
.sp 1P
.LP
9.2
\fIStructure of IP\(hymessages\fR
.sp 9p
.RT
.PP
The IP class of UAs create messages containing a content specific to the
IPM. The specific content that is sent from one IPM UA to another is a
result of an originator composing and sending a message, called an IP\(hymessage.
The structure of an IP\(hymessage as it release to the basic message structure
of MHS is shown in Figure\ 8/X.400. The IP\(hymessage is conveyed with
an envelope
when being transferred through the MTS.
.RT
.PP
Figure 9/X.400 shows an analogy between a typical office memo, and the
corresponding IP\(hymessage structure. The IP\(hymessage contains information
(e.g.,\ to, cc, subject) provided by the user which is transformed by the
IPM UA into the heading of the IP\(hymessage. The main information that
the user wishes to communicate (the body of the memo) is contained within
the body of the
IP\(hymessage. In the example shown, the body contains two types of encoded
information: text and facsimile, which form what are called body parts. In
general, an IP\(hymessage body can consist of a number of body parts, each
which can be of a different encoded information type, such as voice, text,
facsimile and graphics.
.bp
.LP
.rs
.sp 27P
.ad r
\fBFigure 7/X.400, p. 8\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 18P
.ad r
\fBFigure 8/X.400, p. 9\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.LP
.rs
.sp 30P
.ad r
\fBFigure 9/X.400, p. 10\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
9.3
\fIIP\(hynotifications\fR
.sp 9p
.RT
.PP
In the IPM service a user can request a notification of receipt or non\(hyreceipt
of a message by a recipient. These notifications are requested by an originator
and are generated as a result of some (such as reading/not
reading the message) recipient action. In certain cases the non\(hyreceipt
notification is generated automatically by the recipient's UA.
.RT
.sp 2P
.LP
\fB10\fR \fBIntercommunication with physical delivery services\fR
.sp 1P
.RT
.sp 1P
.LP
10.1
\fIIntroduction\fR
.sp 9p
.RT
.PP
The value of message handling systems can be increased by
connecting them to physical delivery (PD) systems such as the traditional
postal service. This will allow for the physical (e.g.,\ hardcopy) delivery
of messages originated within MHS to recipients outside of MHS, and in
some cases will allow for the return of notifications from the PD service
to an MHS
originator. The ability for origination of messages in the PD service for
submission to MHS through the PDAU is for further study. The capability of
intercommunication between PD and MH services is an optional capability
of MHS, and is applicable to any application such as IPM. All users of
MHS will have
the ability to generate messages for subsequent physical delivery.
Figure\ 10/X.400 shows the functional model of this interworking. Provision
of intercommunication between public message handling services offered
by
Administrations and PD services is described in Recommendation\ F.415. The
elements of service describing the features of this intercommunication are
defined in Annex\ B and classified in \(sc\ 19.
.bp
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 10/X.400, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
A physical delivery system is a system, operated by a management domain,
that transports and delivers physical messages. A physical message is a
physical object comprising a relaying envelope and its content. An example
of a PDS is the postal service. An example of a physical message is a paper
letter and its enclosing paper envelope.
.PP
A physical delivery access unit (PDAU) converts an MH user's message to
physical form, a process called physical rendition. An example of this
is
the printing of a message and its automatic enclosure in a paper envelope.
The PDAU passes the physically rendered message to a PDS for further relaying
and eventual physical delivery.
.PP
A PDAU can be viewed as a set of UAs, each UA being identified by a
postal address. To perform its functions, a PDAU must support submission
(notifications) and delivery interactions with the MTS, and also cooperate
with other UAs. MH/PD service intercommunication is thus provided as part
of the
message transfer service.
.PP
To enable MH users to address messages, to be delivered physically by a
PDS, an address form appropriate for this exists and is described in
\(sc\ 12.
.RT
.sp 1P
.LP
10.2
\fIOrganizational configurations\fR
.sp 9p
.RT
.PP
Possible organizational mappings of the functional model described above
are shown in Figure\ 11/X.400. In each model (A\ &\ B), the term\ PD domain
denotes the domain of responsibility of an organization providing a PD
service. In A, the PD domain comprises an MD and a PDS. The boundary between
the PD
domain and the rest of MHS is a boundary between MDs. In B, the PD domain
comprises only the PDS; the PDAU is not part of the PD domain. The boundary
between the PD domain and MHS lies at the point where the PDAU passes physical
messages to the PDS.
.RT
.sp 2P
.LP
\fB11\fR \fBSpecialized access\fR
.sp 1P
.RT
.sp 1P
.LP
11.1
\fIIntroduction\fR
.sp 9p
.RT
.PP
The functional model of MHS (Figure 1/X.400) contains access units (AUs)
to allow access between MHS and other communication systems and services.
The model shows a generic access unit between MHS and telematic services.
.PP
Also shown in a physical delivery access unit to allow for physical
delivery of MHS messages to recipients without the need for terminal access
to MHS. The access to physical delivery services is available to any application
carried by the MTS, through a PDU described in \(sc\ 10.
.PP
Other forms of access are described below.
.bp
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 11/X.400, p. 12\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
11.2
\fITeletex access\fR
.sp 1P
.RT
.sp 1P
.LP
11.2.1
\fIRegistered access to the IPM service\fR
.sp 9p
.RT
.PP
The specialized access unit defined for telematic access \(em
telematic agent (TLMA) caters specially for teletex (TTX) terminals. This
TLMA provides for teletex access to the IPM service as shown in Figure\
7/X.400. The technical provisions of this access are defined in Recommendation\
T.330. The
TLMA enables users of teletex terminals to participate fully in the IPM
service.
.RT
.sp 1P
.LP
11.2.2
\fINon\(hyregistered (public) access to the IPM service\fR
.sp 9p
.RT
.PP
The specialized access unit defined for telematic access \(em
telematic agent (TLMA) also provides for public access to the IPM service
for TTX users who are not registered users of the IPM service. This is
shown in
Figure\ 7/X.400. The technical provisions of this access are defined in
Recommendation\ T.330. The intercommunication between the IPM service and the
teletex service is defined in Recommendation\ F.422.
.RT
.sp 2P
.LP
11.3
\fITelex access\fR
.sp 1P
.RT
.sp 1P
.LP
11.3.1
\fIRegistered access to the IPM service\fR
.sp 9p
.RT
.PP
A telex access unit (TLXAU) is defined in the technical
Recommendations to allow the intercommunication between IPM users and telex
users. To provide a service with this type of AU is a national matter.
.RT
.sp 1P
.LP
11.3.2
\fINon\(hyregistered (public) access to the IPM service\fR
.sp 9p
.RT
.PP
A specialized access unit is defined to allow the
intercommunication between IPM users and telex users. This AU provides for
public access to the IPM service for telex users who are not registered
users of the IPM service, and is called a public telex access unit (PTLXAU).
This is shown in Figure\ 7/X.400. The telex users are not subscribers to
the IPM
service, but use some of the features of the IPM service to pass messages to
IPM users. IPM users can also send messages to telex users via this AU. The
intercommunication between the IPM service and the telex service is defined
in Recommendation\ F.421.
.PP
\fINote\fR \ \(em\ Other types of access units are for further study (e.g.,
facsimile, videotex,\ etc.).
.bp
.RT
.LP
PART\ 3\ \(em\
CAPABILITIES OF MHS
.sp 1P
.RT
.sp 2P
.LP
\fB12\fR \fBNaming and addressing\fR
.sp 1P
.RT
.sp 1P
.LP
12.1
\fIIntroduction\fR
.sp 9p
.RT
.PP
In an MHS, the principal entity that requires naming is the user
(the originator and recipient of messages). In addition, distribution lists
(DLs) have names for use in MHS. Users of MHS and DLs are identified by O/R
names. O/R names are comprised of directory names and/or addresses, all of
which are described in this clause.
.RT
.sp 1P
.LP
12.2
\fIDirectory names\fR
.sp 9p
.RT
.PP
Users of the MH service, and DLs, can be identified by a name,
called a directory name. A directory name must be looked up in a directory
to find out the corresponding O/R address. The structure and components
of
directory names are described in the X.500\(hySeries of Recommendations.
.PP
A user can access a directory system directly to find out the O/R
address of a user, or O/R addresses of the members of a DL (both of which
are outside the scope of these Recommendations). As an alternative, a user
can use the directory name and have MHS access a directory to resolve the
corresponding O/R address or addresses automatically as described in \(sc\
14.
.PP
An MH user or DL will not necessarily have a directory name, unless
they are registered in a directory. As directories become more prevalent,
it is expected that directory names will be the preferred method of identifying
MHS users to each other.
.RT
.sp 1P
.LP
12.3
\fIO/R names\fR
.sp 9p
.RT
.PP
Every MH user or DL will have one or more O/R name(s). An O/R name comprises
a directory name, and O/R address, or both.
.PP
Either or both components of an O/R name can be used on submission of a
message. If only the directory name is present, MHS will access a directory
to attempt to determine the O/R address, which it will then use to route
and
deliver the message. If a directory name is absent, it will use the O/R
address as given. When both are given on submission, MHS will use the O/R
address, but will carry the directory name and present both to the recipient.
If the O/R
address is invalid, it will then attempt to use the directory name as
above.
.RT
.sp 1P
.LP
12.4
\fIO/R addresses\fR
.sp 9p
.RT
.PP
An O/R address contains information that enables MHS to uniquely
identify a user to deliver a message or return a notification to him. (The
prefix \*QO/R\*U recognizes the fact that the user can be acting as either the
originator or recipient of the message or notification in question.)
.PP
An O/R address is a collection of information called attributes.
Recommendation\ X.402 specifies a set of standard attributes from which O/R
addresses can be constructed. Standard attributes mean that their syntax and
semantics are defined in Recommendation\ X.402. In addition to standard
attributes, and to cater for existing messaging systems, there are domain
defined attributes whose syntax and semantics are defined by management
domains.
.PP
Various forms of O/R addresses are defined, each serving their own
purpose. These forms and their purpose are as follows:
.RT
.LP
\(em
\fIMnemonic O/R address:\fR Provides a user\(hyfriendly means of
identifying users in the absence of a directory. It is also used for
identifying a distribution list.
.LP
\(em
\fITerminal O/R address:\fR Provides a means of identifying
users with terminals belonging to various networks.
.LP
\(em
\fINumeric O/R address:\fR Provides a means of identifying users by means
of numeric keypads.
.LP
\(em
\fIPostal O/R address:\fR Provides a means of identifying
originators and recipients of physical messages.
.bp
.sp 2P
.LP
\fB13\fR \fBMHS use of directory\fR
.sp 1P
.RT
.sp 1P
.LP
13.1
\fIIntroduction\fR
.sp 9p
.RT
.PP
The directory defined by the X.500\(hySeries of Recommendations
provides capabilities useful in the use and provision of a variety of
telecommunication services. This clause describes how a directory can be
used in messages handling. Details can be found in other X.400\ Recommendations.
.PP
The directory capabilities used in message handling fall into the
following four categories:
.RT
.LP
a)
\fIUser\(hyfriendly naming:\fR The originator or recipient of a
message can be identified by means of his directory name, rather than his
machine oriented O/R address. At any time MHS can obtain the latter from the
former by consulting the directory.
.LP
b)
\fIDistribution lists (DLs):\fR A group whose membership is
stored in the directory can be used as a DL. The originator simply supplies
the name of the list. At the DL's expansion point MHS can obtain the directory
names (and then the O/R addresses) of the individual recipients by consulting
the directory.
.LP
c)
\fIRecipient UA capabilities:\fR MHS capabilities of a
recipient (or originator) can be stored in his directory entry. At any
time MHS can obtain (and then act upon) those capabilities by consulting
the directory.
.LP
d)
\fIAuthentication:\fR Before two MHS functional entities (two
MTAs, or a UA and an MTA) communicate with one another, each establishes the
identity of the other. This can be done by using authentication capabilities
of MHS based on information stored in the directory.
.PP
Besides the above, one user can directly access the directory, for example,
to determine the O/R address or MHS capabilities of another. The
recipient's directory name is supplied to the directory, which returns the
requested information.
.sp 1P
.LP
13.2
\fIFunctional model\fR
.sp 9p
.RT
.PP
Both UAs and MTAs can use the directory. A UA can present the
directory with the directory name of the intended recipient, and obtain from
the directory the recipient's O/R address. The UA can then supply both the
directory name and the O/R address to the MTS. Another UA can supply just
the recipient's directory name to the MTS. The MTS would then itself ask
the
directory for the recipient's O/R address and add it to the envelope. The
originating MTA normally carries out the name to O/R address look up.
.PP
A functional model depicting the above is shown in Figure
12/X.400.
.RT
.LP
.rs
.sp 20P
.ad r
\fBFigure 12/X.400, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
13.3
\fIPhysical configurations\fR
.sp 9p
.RT
.PP
Some possible physical configurations of the above functional model are
shown in Figure\ 13/X.400. Where a directory user agent (DUA) and directory
system agent (DSA) reside in physically separate systems, a standard directory
protocol, defined in the X.500\(hySeries of Recommendations, governs their
interactions. It will often be desirable to physically co\(hylocate a UA or MTA
with a DUA/DSA. However, other physical configurations are also possible.
.RT
.LP
.rs
.sp 19P
.ad r
\fBFigure 13/X.400, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB14\fR \fBDistribution lists in MHS\fR
.sp 1P
.RT
.sp 1P
.LP
14.1
\fIIntroduction\fR
.sp 9p
.RT
.PP
The ability to make use of a distribution list (DL) is an optional capability
of MHS provided through the MT service. DL expansion allows a sender to
have a message transmitted to a group of recipients, by naming the group
instead of having to enumerate each of the final recipients.
.RT
.sp 1P
.LP
14.2
\fIProperties of a DL\fR
.sp 9p
.RT
.PP
The properties of a DL can be described as follows:
.RT
.LP
\(em
\fIDL members:\fR Users and other DLs that will receive
messages addressed to the DL.
.LP
\(em
\fIDL submit permission:\fR A list of users and other DLs which are allowed
to make use of the DL to send messages to the DL's members.
.LP
\(em
\fIDL expansion point:\fR Each DL has an unambiguous O/R
address. This O/R address identifies the expansion point, which is the
domain or MTA where the names of the members of the DL are added to the
recipient
list. The message is transported to the expansion point before expansion as
shown in Figure\ 14/X.400.
.LP
\(em
\fIDL owner:\fR A user who is responsible for the management of a DL.
.sp 1P
.LP
14.3
\fISubmission\fR
.sp 9p
.RT
.PP
Submission of a message to a DL is similar to the submission of a message
to a user. The originator can include in the DL's O/R name, the
directory name, the O/R address, or both (see \(sc\ 12 for details). The
originator need not be aware that the O/R name used is that of a DL. The
originator can, however, through use of the element of service, DL expansion
prohibited,
prohibit the MTS from expanding a message unknowingly addressed to a DL.
.bp
.RT
.sp 1P
.LP
14.4
\fIDL use of a directory\fR
.sp 9p
.RT
.PP
A directory may or may not be used to store information about the properties
of a DL. Among the information that can be stored are the following: DL
members, DL owner, DL submit permission and the DL expansion point.
.RT
.sp 1P
.LP
14.5
\fIDL expansion\fR
.sp 9p
.RT
.PP
At the expansion point, the MTA responsible for expanding the DL
will:
.RT
.LP
a)
Look up the information about the DL, e.g. in the directory, using access
rights granted to the MTA. (\fINote\fR \ \(em\ Since this is done by the
MTA at the expansion point, support of DLs in MHS does not require a globally
interconnected directory).
.LP
b)
Verify whether expansion is allowed by checking the identity of the sender
against the DL's submit permission.
.LP
c)
If expansion is allowed, add the members of the DL to the
list of recipients of the message and transmit the message to them.
.LP
.rs
.sp 24P
.ad r
\fBFigure 14/X.400, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
14.6
\fINesting\fR
.sp 9p
.RT
.PP
A member of a DL can be another DL as shown in Figure 14/X.400. In this
case the message is forwarded from the expansion point of the parent DL
to the expansion point of the member DL for further expansion. Thus during
each
expansion, only the members of a single DL are added to the message.
.PP
During expansion of a nested DL, the identity of the parent DL (e.g., DL1
in Figure\ 14/X.400) rather than that of the message originator, is compared
against the submit permission of the member\ DL (e.g.,\ DL2 in Figure\
14/X.400).
.PP
\fINote\fR \ \(em\ DL structures can be defined which reference a particular
nested DL more than once at different levels of the nesting. Submission
to such a parent\ DL can cause a recipient to receive multiple copies of
the same
message. The same result can occur if a message is addressed to multiple DLs
which contain a common member. Correlation of such copies can be done at the
recipient's UA, and/or in the MS.
.bp
.RT
.sp 1P
.LP
14.7
\fIRecursion control\fR
.sp 9p
.RT
.PP
If a certain DL is directly or indirectly a member of itself (a
situation which can validly arise), or when DLs are combined with redirection,
then a message might get back to the same list and potentially circulate
infinitely. This is detected by the MTS and prevented from occurring.
.RT
.sp 1P
.LP
14.8
\fIDelivery\fR
.sp 9p
.RT
.PP
On delivery of the message, the recipient will find out that he
received the message as a member of a DL, and through which DL, or chain
or DLs he got the message.
.RT
.sp 1P
.LP
14.9
\fIRouting loop control\fR
.sp 9p
.RT
.PP
A message can be originated in one domain/MTA, expanded in a second domain/MTA,
and then sent back to a DL member in the first domain/MTA. The MTS will
not treat this as a routing loop error.
.RT
.sp 1P
.LP
14.10
\fINotifications\fR
.sp 9p
.RT
.PP
Delivery and non\(hydelivery notifications can be generated both at
the DL expansion point (e.g.\ if submit permission is denied), and at delivery
to the ultimate recipient.
.PP
When a message coming from a DL generates a notification, this
notification is sent to the DL from which the message came. The DL will
then, depending on the policy of the list, forward the notification to
the owner of the list, to the DL or originator from which it got the message,
or both, as
shown in Figure\ 15/X.400.
.RT
.LP
.rs
.sp 11P
.ad r
\fBFigure 15/X.400, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
\fINote\fR \ \(em\ When notifications are sent to the originator after DL
expansion, the originator can receive many delivery/non\(hydelivery notifications
for one originator specified recipient (the DL itself). The originator
can even receive more than one notification from an ultimate recipient,
if that
recipient received the message more than once via different lists.
.sp 1P
.LP
14.11
\fIDL handling policy\fR
.sp 9p
.RT
.PP
An MTA may or may not provide different policies on DL handling.
Such policies will control whether notifications generated at delivery to DL
members should be propagated back through the previous DL, or to the originator
if no such previous DL, and/or to this list owner. If the policy is such
that notifications are to be sent only to the list owner, then the originator
will receive notifications if requested, only during expansion of that
DL. In order to accomplish this restriction, the MTS will, while performing
the expansion, reset the notification requests according to the policy
for the list.
.RT
.sp 2P
.LP
\fB15\fR \fBSecurity capabilities of MHS\fR
.sp 1P
.RT
.sp 1P
.LP
15.1
\fIIntroduction\fR
.sp 9p
.RT
.PP
The distributed nature of MHS makes it desirable that mechanisms
are available to protect against various security threats that can arise.
The nature of these threats and the capabilities to counter them are highlighted
below.
.bp
.RT
.sp 2P
.LP
15.2
\fIMHS security threats\fR
.sp 1P
.RT
.sp 1P
.LP
15.2.1
\fIAccess threats\fR
.sp 9p
.RT
.PP
Invalid user access into MHS is one of the prime security threats to the
system. If invalid users can be prevented from using the system, then
the subsequent security threat to the system is greatly reduced.
.RT
.sp 1P
.LP
15.2.2
\fIInter\(hymessage threats\fR
.sp 9p
.RT
.PP
Inter\(hymessage threats arise from unauthorized agents who are
external to the message communication, and can manifest themselves in the
following ways;
.RT
.LP
\(em
\fIMasquerade:\fR A user who does not have proof of whom he is
talking to can be easily misled by an imposer into revealing sensitive
information.
.LP
\(em
\fIMessage modification:\fR A genuine message which has been
modified by an unauthorized agent while it was transferred through the
system can mislead the message recipient.
.LP
\(em
\fIReplay:\fR Messages whose originators and contents are
genuine can be monitored by an unauthorized agent and could be recorded
to be replayed to the message's intended recipient at a later date. This
could be
done in order to either extract more information from the intended recipient
or to confuse him.
.LP
\(em
\fITraffic analysis:\fR Analysis of message traffic between MH
users can reveal to an eavesdropper how much data (if any) is being sent
between users and how often. Even if the eavesdropper cannot determine the
actual contents of the messages, he can still deduce a certain amount of
information from the rate of traffic flow (e.g.\ continuous, burst, sporadic
or none).
.sp 1P
.LP
15.2.3
\fIIntra\(hymessage threats\fR
.sp 9p
.RT
.PP
Intra\(hymessage threats are those performed by the actual message
communication participants themselves, and can manifest themselves in the
following ways:
.RT
.LP
\(em
\fIRepudiation of messages:\fR One of the actual communication
participants can deny involvement in the communication. This could have
serious implications if financial transactions were being performed via
MHS.
.LP
\(em
\fISecurity level violation:\fR If a management domain within
MHS employs different security clearance levels (e.g.\ public, personal,
private and company confidential) then users must be prevented from sending
or
receiving any messages for which they have an inadequate security clearance
level if the management domain's security is not to be compromised.
.sp 1P
.LP
15.2.4
\fIData store threats\fR
.sp 9p
.RT
.PP
An MHS has a number of data stores within it that must be protected from
the following threats:
.RT
.LP
\(em
\fIModification of routing information:\fR Unauthorized
modification of the directory's contents could lead to messages being
mis\(hyrouted or even lost while unauthorized modification to the deferred
delivery data store or the hold for delivery data store could mislead or
confuse the intended recipient.
.LP
\(em
\fIPreplay:\fR An unauthorized agent could make a copy of a
deferred delivery message and send this copy to the intended recipient while
the original was still being held for delivery in the MTA. This could fool
the message recipient into replying to the message originator before the
originator was expecting a reply or simply mislead or confuse the original
intended
message recipient.
.sp 1P
.LP
15.3
\fISecurity model\fR
.sp 9p
.RT
.PP
Security features can be provided by extending the capabilities of the
components in the message handling system to include various security
mechanisms.
.PP
There are two aspects to security in message handling: secure access management
and administration, and secure messaging.
.RT
.sp 1P
.LP
15.3.1
\fISecure access management and administration\fR
.sp 9p
.RT
.PP
The capabilities in this section cover the establishment of an
authenticated association between adjacent components, and the setting up of
security parameters for the association. This can be applied to any pair of
components in the message handling system: UA/MTA, MTA/MTA, MS/MTA,\ etc.
.bp
.RT
.sp 1P
.LP
15.3.2
\fISecure messaging\fR
.sp 9p
.RT
.PP
The capabilities in this section cover the application of security features
to protect messages in the message handling system in accordance with a
defined security policy. This includes elements of service enabling various
components to verify the origin of messages and the integrity of their
content, and elements of service to prevent unauthorized disclosure of
the message
content.
.PP
The capabilities in this section cover the application of security
features to protect messages directly submitted to the message transfer
system by a user agent, message store, or an access unit. They do not cover
the
application of security features to protect communication between users
and the message handling system, or MH user\(hyto\(hyMH user communication
(a large part of MH user\(hyto\(hyMH user communication is protected between
two UAs). Thus they do
not apply, for example, to communication between a remote user's terminal
and its UA, or to communication between these users' terminal equipment
and other users in the MHS. Security capabilities to protect MH user\(hyto\(hyMH
user
communication are for further study.
.PP
Many of the secure messaging elements of service provide an originator
to recipient capability, and require the use of user agents with security
capabilities. They do not require the use of a message transfer system with
security features. (As an example, content confidentiality can be applied by
enciphering the message content by the originator, and deciphering by the
recipient, with various security parameters transferred within the message
envelope. Such a message can be transferred by an MTS which can handle the
format of the content (unformatted octets), and transparently handle the
security fields in the envelope.)
.PP
Some of the secure messaging elements of service involve an
interaction with the message transfer system, and require the use of message
transfer agents with security capabilities. (As an example, non\(hyrepudiation
of submission requires the MTA, to which the message is submitted, to contain
mechanisms to generate a proof of submission field.)
.PP
Some of the secure messaging elements of service apply to the MS as
well as UAs and MTAs, such as message security labelling. In general, however,
the MS is transparent to security features that apply between the originators'
and the recipients' UAs.
.PP
The scope of the secure messaging elements of service is given in
Table 2/X.400. This describes the elements of service in terms of which MHS
component is the \*Qprovider\*U or which is the \*Quser\*U of the security
service. For example, probe origin authentication is provided by the originating
UA, and can be used by the MTAs through which the probe passes.
.PP
This Recommendation describes the use of security services by the UA, and
the MTA. How these features are applied to access units is for further
study.
.RT
.sp 1P
.LP
15.4
\fIMHS security capabilities\fR
.sp 9p
.RT
.PP
The elements of service describing the security features of MHS are defined
in Annex\ B, and classified in\ \(sc\ 19. An overview of these capabilities
is as follows:
.RT
.LP
\(em
\fIMessage origin authentication:\fR Enables the recipient, or
any MTA through which the message passes, to authenticate the identity
of the originator of a message.
.LP
\(em
\fIReport origin authentication:\fR Allows the originator to
authenticate the origin of a delivery/non\(hydelivery report.
.LP
\(em
\fIProbe origin authentication:\fR Enables any MTA through
which the probe passes, to authenticate the origin of the probe.
.LP
\(em
\fIProof of delivery:\fR Enables the originator of a message to authenticate
the delivered message and its content, and the identity of the
recipient(s).
.LP
\(em
\fIProof of submission:\fR Enables the originator of a message
to authenticate that the message was submitted to the MTS for delivery
to the originally specified recipient(s).
.LP
\(em
\fISecure access management:\fR Provides for authentication
between adjacent components, and the setting up of the security context.
.LP
\(em
\fIContent integrity:\fR Enables the recipient to verify that
the original content of a message has not been modified.
.LP
\(em
\fIContent confidentiality:\fR Prevents the unauthorized
disclosure of the content of a message to a party other than the intended
recipient.
.bp
.LP
\(em
\fIMessage flow confidentiality:\fR Allows the originator of a
message to conceal the message flow through MHS.
.LP
\(em
\fIMessage sequence integrity:\fR Allows the originator to
provide to a recipient proof that the sequence of messages has been preserved.
.LP
\(em
\fINon\(hyrepudiation of origin:\fR Provides the recipient(s) of a message
with proof of origin of the message and its content which will protect
against any attempt by the originator to falsely deny sending the message
or
its content.
.LP
\(em
\fINon\(hyrepudiation of delivery:\fR Provides the originator of a message
with proof of delivery of the message which will protect against any
attempt by the recipient(s) to falsely deny receiving the message of its
content.
.LP
\(em
\fINon\(hyrepudiation of submission:\fR Provides the originator of a
message with proof of submission of the message, which will protect against
any attempt by the MTS to falsely deny that the message was submitted for
delivery to the originally specified recipient(s).
.LP
\(em
\fIMessage security labelling:\fR Provides a capability to
categorize a message, indicating its sensitivity, which determines the
handling of a message in line with the security policy in force.
.ce
\fBH.T. [T2.400]\fR
.ce
TABLE\ 2/X.400
.ce
\fBProvision and use of secure messaging elements
.ce
of service by MHS components
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(42p) | cw(24p) | cw(42p) .
Elements of service Originating MTS user MTS Recipient MTS user
_
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Message origin authentication P U U
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Report origin authentication U P \(em
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Probe origin authentication P U \(em
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Proof of delivery U \(em P
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Proof of submission U P \(em
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Secure access management P U P
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Content integrity P \(em U
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Content confidentiality P \(em U
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Message flow confidentiality P \(em \(em
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Message sequence integrity P \(em U
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Non\(hyrepudiation of origin P \(em U
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
T{
Non\(hyrepudiation of submission
T} U P \(em
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
T{
Non\(hyrepudiation of delivery
T} U \(em P
.T&
lw(120p) | cw(42p) | cw(24p) | cw(42p) .
Message security labelling P U T{
U
P
The MHS component is a provider of the service.
.parag
U
The MHS component is a user of the service.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 2/X.400 [T2.400], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
.sp 2
15.5
\fISecurity management\fR
.sp 9p
.RT
.PP
Aspects of an asymmetric key management scheme to support the
above features are provided by the directory system authentication framework,
described in Recommendation\ X.509. The directory stores certified copies
of
public keys for MHS users which can be used to provide authentication and to
facilitate key exchange for use in data confidentiality and data integrity
mechanisms. The certificates can be read from the directory using the directory
access protocol described in Recommendation\ X.519.
.PP
Recommendations for other types of key management schemes, including symmetric
encryption, to support the security features are for further
study.
.bp
.RT
.sp 2P
.LP
\fB16\fR \fBConversion in MHS\fR
.sp 1P
.RT
.PP
The MTS provides conversion functions to allow users to input
messages in one or more encoded formats, called encoded information types
(EITs), and have them delivered in other EITs to cater to users with various
UA capabilities and terminal types. This capability is inherent in the
MTS and
increases the possibility of delivery by tailoring the message to the
recipient's terminal capabilities. The EITs standardized in MHS are listed
in Recommendation\ X.411. Conversions and the use of the elements of service
relating to conversion are available for EITs not defined in
Recommendation\ X.411, but supported by certain domains, either bilaterally
between these domains or within a domain itself.
.PP
MHS users have some control over the conversion process through
various elements of service as described in Annex\ B. These include the
ability for a user to explicitly request the conversion required or as
a default to let the MTS determine the need for conversion, and the type
of conversion
performed. Users also have the ability to request that conversion not be
performed or that conversion not be performed if loss of information will
result. When the MTS performs conversion on a message it informs the UA
to whom the message is delivered that conversion took place and what the
original EITs were.
.PP
The conversion process for IP\(hymessages can be performed on body parts
of specific types if they are present in a message. The general aspects
of
conversion and the specific conversion rules for conversion between different
EITs are detailed in Recommendation\ X.408.
.PP
Recommendation X.408 deals with conversion for the following: telex, IA5
text, teletex, G3fax, G4\ Class1, videotex, voice, and mixed mode.
.RT
.sp 2P
.LP
\fB17\fR \fBUse of the MHS in provision of public services\fR
.sp 1P
.RT
.PP
The message handling system is used in the provision of public MH services
that are offered by Administrations for use by their subscribers.
These public MH services are defined in the F.400\(hySeries Recommendations and
include:
.RT
.LP
\(em
the public message transfer service (Rec. F.410);
.LP
\(em
the public interpersonal messaging service
(Rec. F.420).
.PP
In addition complementary public services are offered by
Administrations to allow for the intercommunication between CCITT services
and the public MH services mentioned above, as follows:
.LP
\(em
intercommunication with public physical delivery services
(Rec.\ F.415).
.LP
\(em
intercommunication between the IPM service and the telex
service (Rec.\ F.421);
.LP
\(em
intercommunication between the IPM service and the teletex
service (Rec.\ F.422);
.PP
Recommendation F.401 describes the naming and addressing aspects for public
MH services.
.LP
.rs
.sp 16P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.LP
PART\ 4\ \(em\ ELEMENTS OF SERVICE
.sp 1P
.RT
.sp 2P
.LP
\fB18\fR \fBPurpose\fR
.sp 1P
.RT
.PP
Elements of service are particular features, functions, or
capabilities of MHS. All the elements of service applicable for MHS are
defined in Annex\ B, where they are listed in alphabetical order with a
corresponding
reference number. The realization of these elements of service in MHS are
described in other Recommendations in the X.400\ Series.
.PP
Elements of service are associated with the various services provided in
MHS. There are elements of service for the message transfer service which
provide for a basic capability for sending and receiving messages between
UAs. There are elements of service for the interpersonal messaging service
which
provide for the sending and receiving of messages between a particular
class of UAs called IPM UAs. There are elements of service for the physical
delivery
service, enabling MH users to send messages and have them delivered in a
physical medium to non\(hyMH users. There are elements of service specifically
available for the use of message stores.
.PP
The elements of service for the IPM service include those available
for the MT service, the PD service, and the message store as well as specific
ones applicable to the IPM service.
.PP
Table 3/X.400 lists all the elements of service available in MHS,
shows what service they are specifically associated with of the presently
defined services, MT service, IPM service, and PD service, or whether they
are specific to the message store, and gives the corresponding reference
number to the definition in Annex\ B.
.RT
.LP
.rs
.sp 34P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [1T3.400]\fR
.ce
TABLE\ 3/X.400
.ce
\fBMHS elements of service\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Elements of service MT IPM PD MS Annex B reference
_
.T&
lw(126p) | cw(18p) | lw(18p) | lw(18p) | lw(18p) | cw(30p) .
Access management X B.1\
.T&
lw(126p) | cw(18p) | lw(18p) | cw(18p) | lw(18p) | cw(30p) .
Additional physical rendition X B.2\
.T&
lw(126p) | cw(18p) | lw(18p) | cw(18p) | lw(18p) | cw(30p) .
Alternate recipient allowed X B.3\
.T&
lw(126p) | cw(18p) | lw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Alternate recipient assignment
T} X B.4\
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Authorizing users indication X B.5\
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Auto\(hyforwarded indication X B.6\
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Basic physical rendition X B.7\
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Blind copy recipient indication
T} X B.8\
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Body part encryption indication
T} X B.9\
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Content confidentiality X B.10
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Content integrity X B.11
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Content type indication X B.12
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Conversion prohibition X B.13
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Conversion prohibition in case of loss information
T} X B.14
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Converted indication X B.15
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Counter collection X B.16
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Counter collection with advice
T} X B.17
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Cross\(hyreferencing indication
T} X B.18
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Deferred delivery X B.19
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Deferred delivery cancellation
T} X B.20
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Delivery notification X B.21
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Delivery time stamp indication
T} X B.22
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Delivery via Bureaufax service
T} X B.23
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Designation of recipient by directory name
T} X B.24
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Disclosure of other recipients
T} X B.25
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
DL expansion history indication
T} X B.26
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
DL expansion prohibited X B.27
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
EMS (express mail service) X B.28
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Expiry date indication X B.29
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Explicit conversion X B.30
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Fowarded IP\(hymessage indication
T} X B.31
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Garde of delivery selection X B.32
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Hold for delivery X B.33
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Implicit conversion X B.34
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Importance indication X B.35
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Incomplete copy indication X B.36
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
IP\(hymessage identification X B.37
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Language indication X B.38
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Latest delivery designation X B.39
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Message flow confidentiality X B.40
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Message identification X B.41
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Message origin authentication X B.42
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Message security labelling X B.43
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Message sequence integrity X B.44
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Multi\(hydestination delivery X B.45
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Multi\(hypart body X B.46
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Non\(hydelivery notification X B.47
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 3/X.400 [1T3.400], p. 18\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [2T3.400]\fR
.ce
TABLE\ 3/X.400\ \fI(cont.)\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Elements of service MT IPM PD MS Annex B reference
_
.T&
lw(126p) | lw(18p) | cw(18p) | lw(18p) | lw(18p) | cw(30p) .
T{
Non\(hyreceipt notification request indication
T} X B.48
.T&
lw(126p) | cw(18p) | cw(18p) | lw(18p) | lw(18p) | cw(30p) .
T{
Non\(hyrepudiation of delivery
T} X B.49
.T&
lw(126p) | cw(18p) | cw(18p) | lw(18p) | lw(18p) | cw(30p) .
Non\(hyrepudiation of origin X B.50
.T&
lw(126p) | cw(18p) | cw(18p) | lw(18p) | lw(18p) | cw(30p) .
T{
Non\(hyrepudiation of submission
T} X B.51
.T&
lw(126p) | cw(18p) | cw(18p) | lw(18p) | lw(18p) | cw(30p) .
Obsoleting indication X B.52
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Ordinary mail X B.53
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Original encoded information types indication
T} X B.54
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Originator indication X B.55
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Originator requested alternate recipient
T} X B.56
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Physical delivery notification by MHS
T} X B.57
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Physical delivery notification by PDS
T} X B.58
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Physical forwarding allowed X B.59
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Physical fowarding prohibited X B.60
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Prevention of non\(hydelivery notification
T} X B.61
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Primary and copy recipients indication
T} X B.62
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Probe X B.63
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Probe origin authentication X B.64
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Proof of delivery X B.65
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Proof of submission X B.66
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Receipt notification request indication
T} X B.67
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Redirection disallowed by originator
T} X B.68
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Redirection of incoming messages
T} X B.69
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Registered mail X B.70
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Registered mail to addressee in person
T} X B.71
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Reply request indication X B.72
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Replying IP\(hymessage indication
T} X B.73
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Report origin authentication X B.74
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
T{
Request for forwarding address
T} X B.75
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Requested delivery method X B.76
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Restricted delivery X B.77
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Return of content X B.78
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Secure access management X B.79
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Sensitivity indication X B.80
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(30p) .
Special delivery X B.81
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Stored message alert X B.82
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
T{
Stored message auto\(hyforward
T} X B.83
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Stored message deletion X B.84
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Stored message fetching X B.85
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Stored message listing X B.86
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Stored message summary X B.87
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Subject indication X B.88
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
T{
Submission time stamp indication
T} X B.89
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Type body X B.90
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
T{
Undeliverable mail with return of physical message
T} X B.91
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
Use of distribution list X B.92
.T&
lw(126p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(30p) .
T{
User/UA capabilities registration
T} X B.93
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 3/X.400 [2T3.400], p. 19\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fB19\fR \fBClassification\fR
.sp 1P
.RT
.sp 1P
.LP
19.1
\fIPurpose of classification\fR
.sp 9p
.RT
.PP
The elements of service of MHS are classified either as belonging to a
basic (also called base for PD and MS) service, or as optional user
facilities. Elements of service belonging to a basic service are inherently
part of that service \(em\ they constitute the basic service and are always
provided and available for use of that service.
.PP
Other elements of service, called optional user facilities, can be
selected by the subscriber or user, either on a per\(hymessage basis, or for an
agreed contractual period of time. Each optional user facility is classified
as either essential or additional. Essential (E) optional user facilities
are to be made available to all MH users. Additional (A) optional user
facilities can be made available for national use, and for international
use on the basis of bilateral agreement.
.RT
.sp 1P
.LP
19.2
\fIBasic message transfer service\fR
.sp 9p
.RT
.PP
The basic MT service enables a UA to submit and to have messages
delivered to it. If a message cannot be delivered, the originating UA is so
informed through a non\(hydelivery notification. Each message is uniquely and
unambiguously identified. To facilitate meaningful communication, a UA can
specify the encoded information type(s) that can be contained in messages
which are delivered to it. The content type and original encoded information
type(s) of a message and an indication of any conversions that have been
performed, and the resulting encoded information type(s), are supplied
with each delivered
message. In addition, the submission time and delivery time are supplied
with each message. The MT elements of service belonging to the basic MT
service are listed in Table\ 4/X.400.
.RT
.ce
\fBH.T. [T4.400]\fR
.ce
.ce
TABLE\ 4/X.400
.ce
\fBElements of service belonging to the basic MT service\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(42p) .
Elements of service Annex B ref.
_
.T&
lw(120p) | cw(42p) .
Access management B.1\
.T&
lw(120p) | cw(42p) .
Content type indication B.12
.T&
lw(120p) | cw(42p) .
Converted indication B.15
.T&
lw(120p) | cw(42p) .
T{
Delivery time stamp indication
T} B.22
.T&
lw(120p) | cw(42p) .
Message indication B.41
.T&
lw(120p) | cw(42p) .
Non\(hydelivery notification B.47
.T&
lw(120p) | cw(42p) .
T{
Original encoded information types indication
T} B.54
.T&
lw(120p) | cw(42p) .
T{
Submission time stamp indication
T} B.89
.T&
lw(120p) | cw(42p) .
T{
User/UA capabilities registration
T} B.93
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 4/X.400 [T4.400], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.sp 2
.sp 1P
.LP
19.3
\fIMT service optional user facilities\fR
.sp 9p
.RT
.PP
Optional user facilities for the MT service can be selected on a
per\(hymessage basis, or for an agreed period of time. Each optional user
facility is classified as either essential or additional as described in
\(sc\ 19.1.
Table\ 5/X.400 lists the elements of service comprising the optional user
facilities of the MT service with their classification and their availability
(PM: per\(hymessage; CA: contractual agreement). Optional user facilities
for the PD service and the message store, while forming a part of the MT
service
optional user facilities, are not listed in this table because they are
subject to either a PDAU or an MS being supplied, and are given separate
classifications in Tables\ 6/X.400\(hy9/X.400.
.bp
.RT
.ce
\fBH.T. [T5.400]\fR
.ce
.ce
TABLE\ 5/X.400
.ce
\fBMT service optional user facilities\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(36p) | cw(36p) | cw(36p) .
Elements of service Classification Available Annex B ref.
_
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Alternate recipient allowed E PM B.3\
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Alternate recipient assignment
T} A CA B.4\
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Content confidentiality A PM B.10
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Content integrity A PM B.11
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Conversion prohibition E PM B.13
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Conversion prohibition in case of loss of information
T} A PM B.14
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Deffered delivery E PM B.19
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Defered delivery cancellation E PM B.20
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Delivery notification E PM B.21
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Designation of recipient by directory name
T} A PM B.24
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Disclosure of other recipients
T} E PM B.25
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
DL expansion history indication
T} E PM B.26
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
DL expansion prohibited A PM B.27
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Explicit conversion A PM B.30
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Grade of delivery selection E PM B.32
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Hold for delivery A CA B.33
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Implicit conversion A CA B.34
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Lastest delivery designation A PM B.39
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Message flow confidentiality A PM B.40
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Message origin authentication A PM B.42 \fR
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Message security labelling A PM B.43
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Message sequence integrity A PM B.44
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Multi\(hydestination delivery A PM B.45
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Non\(hyrepudiation of delivery
T} A PM B.49
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Non\(hyrepudiatation of origin
T} A PM B.50
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Non\(hyrepudiation of submission
T} A PM B.51
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Originator requested alternate recipient
T} A PM B.56
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Prevention of non\(hydelivery notification
T} A PM B.61
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Probe E PM B.63
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Probe origin authentication A PM B.64
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Proof of delivery A PM B.65
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Proof of submission A PM B.66
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Redirection disallowed by originator
T} A PM B.68
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
T{
Redirection of incoming messages
T} A CA B.69
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Report origin authentication A PM B.74
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Requested delivery method E\|\ua\d\u)\d PM B.76
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Restricted delivery A CA B.77
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Return of content A PM B.78
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Secure access management A CA B.79
.T&
lw(120p) | lw(36p) | cw(36p) | cw(36p) .
Use of distribution list A PM T{
B.92
\ua\d\u)\d
Does not imply the provision of all delivery methods which may be requested.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 5/X.400 [T5.400], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
19.4
\fIBase MH/PD service intercommunication\fR
.sp 9p
.RT
.PP
The base MH/PD service intercommunication can be supplied, to
enhance the MT service, and enables messages to be delivered to recipients
in a physical (typically hard copy) format via a physical delivery service
such as the postal service. This capability is applicable for use by any
application
making use of the MT service. The MH/PD elements of service belonging to the
base MH/PD service intercommunication are available on a per\(hyrecipient basis
and are listed in Table\ 6/X.400. When this intercommunication is provided,
through a PDAU, all the elements of service shown in Table\ 6/X.400 shall be
supported.
.RT
.ce
\fBH.T. [T6.400]\fR
.ce
TABLE\ 6/X.400
.ce
\fBElements of service belonging to the base MH/PD\fR
.ce
\fB service intercommunication\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(42p) .
Elements of service Annex B ref.
_
.T&
lw(120p) | cw(42p) .
Basic physical rendition B.7\
.T&
lw(120p) | cw(42p) .
Ordinary mail B.53
.T&
lw(120p) | cw(42p) .
Physical forwarding allowed B.59
.T&
lw(120p) | cw(42p) .
T{
Undeliverable mail with return of physical message
T} B.91
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 6/X.400 [T6.400], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
19.5
\fIOptional user facilities for MH/PD service intercommunication\fR
.sp 9p
.RT
.PP
Base MH/PD elements of servie \(sc 19.4) together with the optional
user facilities listed below, can be used together for the provision of the
MH/PD service intercommunication. This capability is applicable for use
by any application making use of the enhanced MT service. These optional
user
facilities can be selected on a per\(hyrecipient basis and are listed in
Table\ 7/X.400.
.RT
.ce
\fBH.T. [T7.400]\fR
.ce
TABLE\ 7/X.400
.ce
\fBOptional user facilities for MH/PD service intercommunication\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(132p) | cw(36p) | cw(36p) .
Elements of service Classification Annex B ref.
_
.T&
lw(132p) | cw(36p) | cw(36p) .
Additional physical rendition A B.2\
.T&
lw(132p) | cw(36p) | cw(36p) .
Counter collection E B.16
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Counter collection with advice
T} A B.17
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Delivery via Bureaufax service
T} A B.23
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
EMS (express mail service)\|\ua\d\u)\d
T} E B.28
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Physical delivery notification by MHS
T} A B.57
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Physical delivery notification by PDS
T} A B.58
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Notification forwarding prohibited
T} A B.60
.T&
lw(132p) | cw(36p) | cw(36p) .
Registered mail A B.70
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Registered mail to addressee in person
T} A B.71
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Request for forwarding address
T} A B.75
.T&
lw(132p) | cw(36p) | cw(36p) .
Special delivery\|\ua\d\u)\d E T{
B.81
\ua\d\u)\d
At least one or the other shall be supported by the PDAU
and the associated PDS.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 7/X.400 [T7.400], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
19.6
\fIBase message store\fR
.sp 9p
.RT
.PP
The base message store is optionally available to provide for
storage and management of incoming messages acting as an intermediary between
a UA and an MTA. The MS is applicable for use in any application making
use of
the MT service. The elements of service belonging to the base message store
are listed in Table\ 8/X.400. When an MS is provided, all the elements
of service
shown in Table\ 8/X.400 shall be supported.
.RT
.ce
\fBH.T. [T8.400]\fR
.ce
TABLE\ 8/X.400
.ce
\fBBase message store
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(42p) .
Elements of service Annex B ref.
_
.T&
lw(120p) | cw(42p) .
Stored message deletion B.84
.T&
lw(120p) | cw(42p) .
Stored message fetching B.85
.T&
lw(120p) | cw(42p) .
Stored message listing B.86
.T&
lw(120p) | cw(42p) .
Stored message summary B.87
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 8/X.400 [T8.400], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
.sp 1
19.7
\fIMS optional user facilities\fR
.sp 9p
.RT
.PP
Base MS elements of service (\(sc 19.6) together with the optional
user facilities listed below can be used together for enhanced use of a
message store. The enhanced MS is applicable for use in any application
making use of the MT service. The elements of service comprising the MS
optional user
facilities are listed in Table\ 9/X.400.
.RT
.ce
\fBH.T. [T9.400]\fR
.ce
TABLE\ 9/X.400
.ce
\fBMS optional user facilities\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(132p) | cw(36p) | cw(36p) .
Elements of service Classification Annex B ref.
_
.T&
lw(132p) | cw(36p) | cw(36p) .
Stored message alert A B.82
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Stored message auto\(hyforward
T} A B.83
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 9/F.400 [T9.400], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
.sp 1
19.8
\fIBasic interpersonal messaging service\fR
.sp 9p
.RT
.PP
The basic IPM service, which makes use of the MT service, enables a user
to send and receive IP\(hymessages. A user prepares IP\(hymessages with
the
assistance of his user agent (UA). User agents cooperate with each other to
facilitate communication between their respective users. To send an IP\(hymessage,
the originating user submits the message to his UA specifying the O/R name
of the recipient who is to receive the IP\(hymessage. The IP\(hymessage,
which has an
identifier conveyed with it, is then sent by the originator's UA to the
recipient's UA via the message transfer service.
.bp
.PP
Following a successful delivery to the recipient's UA, the IP\(hymessage
can be received by the recipient. To facilitate meaningful communication,
a
recipient can specify the encoded information type(s) contained in IP\(hymessages
that he will allow to be delivered to his UA. The original encoded information
type(s) and an indication of any conversions that have been performed and
the resulting encoded information type(s) are supplied with each delivered
IP\(hymessage. In addition, the submission time and delivery time are supplied
with each IP\(hymessage. Non\(hydelivery notification is provided with
the basic
service. The IPM elements of service belonging to the basic IPM service are
listed in Table\ 10/X.400.
.RT
.ce
\fBH.T. [T10.400]\fR
.ce
TABLE\ 10/X.400
.ce
\fBElements of service belonging to the basic IPM service\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(42p) .
Elements of service Annex B ref.
_
.T&
lw(120p) | cw(42p) .
Access management B.1\
.T&
lw(120p) | cw(42p) .
Content type indication B.12
.T&
lw(120p) | cw(42p) .
Converted indication B.15
.T&
lw(120p) | cw(42p) .
T{
Delivery time stamp indication
T} B.22
.T&
lw(120p) | cw(42p) .
IP\(hymessage identification B.37
.T&
lw(120p) | cw(42p) .
Message identification B.41
.T&
lw(120p) | cw(42p) .
Non\(hydelivery notification B.47
.T&
lw(120p) | cw(42p) .
T{
Original encoded information types indication
T} B.54
.T&
lw(120p) | cw(42p) .
T{
Submission time stamp indication
T} B.89
.T&
lw(120p) | cw(42p) .
Typed body B.90
.T&
lw(120p) | cw(42p) .
T{
User/UA capabilities registration
T} B.93
_
.TE
.nr PS 9
.RT
.ad r
\fBTable 10/X.400 [T10.400], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
19.9
\fIIPM service optional user facilities\fR
.sp 9p
.RT
.PP
A set of the elements of service of the IPM service are optional
user facilities. The optional user facilities of the IPM service, which
can be selected on a per\(hymessage basis or for an agreed contractual
period of time,
are listed in Table\ 11/X.400 and Table\ 12/X.400, respectively. Local user
facilities can be usefully provided in conjunction with some of these user
facilities.
.PP
The optional user facilities of the IPM service that are selected on a
per\(hymessage basis are classified for both origination and reception
by UAs. If an MD offers these optional user facilities for origination
by UAs, then a user is able to create and send IP\(hymessages according
to the procedures defined for the associated element of service. If an
MD offers these optional user
facilities for reception by UAs, MSs and AUs, then the receiving UA, MS and
PDAU will be able to receive and recognize the indication associated with
the corresponding element of service and to inform the user of the requested
optional user facility. Each optional user facility is classified as additional
(A) or essential (E) for UAs from these two perspectives.
.PP
\fINote\fR \ \(em\ With the access protocol described in Recommendation
T.330, teletex terminals are able to make use of the basic IPM service
as well as of the optional user facilities provided by the message handling
system.
.bp
.RT
.ce
\fBH.T. [1T11.400]\fR
.ce
TABLE\ 11/X.400
.ce
\fBIPM optional user facilities selectable on a per\(hymessage basis\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(138p) | cw(30p) | cw(30p) | cw(30p) .
Elements of service Origination Reception Annex B ref.
_
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Additional physical rendition A A B.2\
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Alternate recipient allowed A A B.3\
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Authorizing users indication A E B.5\
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Auto\(hyforwarded indication A E B.6\
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Basic physical rendition A E* B.7\
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Blind copy recipient indication
T} A E B.8\
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Body part encryption indication
T} A E B.9\
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Content confidentiality A A B.10
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Content integrity A A B.11
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Conversion prohibition E E B.13
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Conversion prohibition in case of loss of information
T} N/A B.14
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Counter collection A E* B.16
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Counter collection with advice
T} A A B.17
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Cross\(hyreferencing indication
T} A E B.18
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Deffered delivery E N/A B.19
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Deffered delivery cancellation
T} A N/A B.20
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Delivery notification E N/A B.21
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Delivery via Bureaufax service
T} A A B.23
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Designation of recipient by directory name
T} A N/A B.24
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Disclosure of other recipients
T} A E B.25
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
DL expansion history indication
T} N/A E B.26
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
DL expansion prohibited A A B.27
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
EMS (express mail service)\|\ua\d\u)\d
T} A E* B.28
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Expiry date indication A E B.29
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Explicit conversion A N/A B.30
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Forwarded IP\(hymessage indication
T} A E B.31
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Grade of delivery selection E E B.32
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Importance indication A E B.35
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Incomplete copy indication A A B.36
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Language indication A E B.38
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Latest delivery designation A N/A B.39
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Message flow confidentiality A N/A B.40
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Message origin authentication A A B.42
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Message security labelling A A B.43
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Message sequence integrity A A B.44
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Multi\(hydestination delivery E N/A B.45
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Multi\(hypart body A E B.46
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Non\(hyreceipt notification request indication
T} A E B.48
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Non\(hyrepudiation of delivery
T} A A B.49
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Non\(hyrepudiation of origin A A B.50
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Non\(hyrepudiation of submission
T} A A B.51
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Obsoleting indication A E B.52
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Ordinary mail A E* B.53
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Originator indication E E B.55
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Originator requested alternate recipient
T} A N/A B.56
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Physical delivery notification by MHS
T} A A B.57
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Physical delivery notification by PDS
T} A E* B.58
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Physical forwarding allowed A E* B.59
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 11/X.400 [1T11.400], p. 27\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [2T11.400]\fR
.ce
TABLE\ 11/X.400\ \fI(cont.)\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(138p) | cw(30p) | cw(30p) | cw(30p) .
Elements of service Origination Reception Annex B ref.
_
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Physical forwarding prohibited
T} A E* B.60
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Prevention of non\(hydelivery notification
T} A N/A B.61
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Primary and copy recipients indication
T} E E B.62
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Probe A N/A B.63
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Probe origin authentication A A B.64
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Proof of delivery A A B.65
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Proof of submission A A B.66
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Receipt notification request indication
T} A A B.67
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Redirection disallowed by originator
T} A N/A B.68
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Registred mail A A B.70
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Registred mail to addressee in person
T} A A B.71
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Reply request indication A E B.72
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Reply IP\(hymessage indication
T} E E B.73
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Report origin authentication A A B.74
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Request for forwarding address
T} A \fR A B.75
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Requested delivery method E N/A B.76
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Return of content A N/A B.78
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Sensitivity indication A E B.80
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Special delivery\|\ua\d\u)\d A E* B.81
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Stored message deletion N/A E** B.84
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Stored message fetching N/A E** B.85
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Stored message listing N/A E** B.86
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Stored message summary N/A E** B.87
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Subject indication E E B.88
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
T{
Undeliverable mail with return of physical message
T} A E* B.91
.T&
lw(138p) | cw(30p) | cw(30p) | cw(30p) .
Use of distribution list A A T{
B.92
E
Essential optional user facility has to be provided.
.parag
E*
Essential optional user facility only applying to PDAUs.
.parag
E**
Essential optional user facility only applying to MSs.
.parag
A
Additional optional user facility can be provided.
.parag
N/A
Not applicable.
.parag
\ua\d\u)\d
At least EMS or special delivery shall be supported by the
PDAU and associated PDS.
.parag
\fINote\fR
\ \(em\ Bilateral agreement may be necessary in cases of reception by
UA of elements of service classified by A.
.parag
T}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 11/X.400 [2T11.400], p. 28\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 07P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T12.400]\fR
.ce
TABLE\ 12/X.400
.ce
\fBIPM optional user facilities agreed for a contractual
.ce
period of time
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(132p) | cw(36p) | cw(36p) .
Elements of service Classification Annex B ref.
_
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Alternate recipient assignment
T} A B.4\
.T&
lw(132p) | cw(36p) | cw(36p) .
Hold for delivery A B.33
.T&
lw(132p) | cw(36p) | cw(36p) .
Implicit conversion A B.34
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Redirection of incoming messages
T} A B.69
.T&
lw(132p) | cw(36p) | cw(36p) .
Restricted delivery A B.77
.T&
lw(132p) | cw(36p) | cw(36p) .
Secure access management A B.79
.T&
lw(132p) | cw(36p) | cw(36p) .
Stored message alert A B.82
.T&
lw(132p) | cw(36p) | cw(36p) .
T{
Stored message auto\(hyforward
T} A B.83
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau 12/X.400 [T12.400], p. 29\fR
.sp 1P
.RT
.ad b
.RT
.LP
.rs
.sp 34P
.ad r
BLANC
.ad b
.RT
.sp 2P
.LP
\fBMONTAGE:\fR \ \ \
Annexe A sur le reste de cette page
.sp 1P
.RT
.LP
.bp